A database is, fundamentally, a computerized record-keeping system in which large amounts of information may be stored in a structured manner for ease of subsequent retrieval and processing. Large databases such as the DB2® database from the International Business Machines Corporation of Armonk, N.Y., are typically managed through a database management system (“DBMS”). A DBMS, in turn, provides four primary functions: management of physical storage; a user interface (e.g., the Structured Query Language, “SQL”); data security (e.g., user passwords and view restriction policies); and (4) data consistency or integrity.
There are two types of consistency—physical and transactional. Physical consistency refers to the integrity between physical pages of storage. For example, index pointers must be consistent with the data pages to which they point, a pointer record and the overflow record it points to on another page must be consistent, an index non-leaf page and the leaf page it points to must be consistent, and any DBMS defined referential integrity constraints established between database objects must be maintained in the face of data updates. Transactional consistency refers to the condition wherein a database's data is consistent across (although not necessarily during) a transaction. A transaction is generally defined as all database operations (e.g., updates) associated with a single logical action. To permit the DBMS to track transactions comprising multiple operations, and to maintain the database's integrity in light of such operations (i.e., transactional consistency), all database operations related to a transaction are grouped into a single unit of work (“UOW”). Until all updates in a UOW are committed (that is, applied to and made part of the database object to which they are directed and such action noted in the DBMS's log files), the UOW is said to be “in-flight.”
It is important that when generating a copy of a database (or a portion thereof) the resulting copy is both physically and transactionally consistent. To ensure this consistency, prior art database copy techniques (1) block write-access to the database objects being copied, including all referentially related objects, (2) wait for all in-flight UOWs to complete, and (3) copy the database objects. While this process generates a consistent copy of the database objects as of the time the copy operation was initiated, it prevents users from updating the database objects at least until the in-flight UOWs are complete. This can be a significant drawback for large or complex databases and/or those databases that experience large update volumes.
Techniques for generating point-in-time consistent copies of a database (or portions thereof) are disclosed in U.S. Pat. No. 7,133,884, which is incorporated herein by reference in its entirety. In some situations, users may not effectively be able to apply log records to a consistent copy to recover an image of the database objects to the current time or to a point-in-time after the copy was made. For example, simply applying log records in a normal manner to the consistent copy may be ineffectual because any changes made to database objects by transactions that were in-flight at the time the copy was made may be lost. To overcome this problem, users may need to resort to less than ideal or efficient solutions. For example, users may need to make multiple copies of database objects—one copy for recovering to the point-in-time when the copy was made and another copy for applying log records to recover to the current time or a point-in-time after the copy was made.
The subject matter of the present disclosure is directed to, inter alia, overcoming or at least reducing the effects of one or more of the problems set forth above. For example, the subject matter of the present disclosure can enable recovery to the current time or other point-in-time after a copy was made without having to make multiple copies of the data.